To discuss here which of the added # noqa could be avoided

@happz one question, in the related issue with the patch it's used tmt -a provision -h local which IIUC it's the local host already executing tmt, in this case the code raises again permissions issues when doing the chmod

@happz one question, in the related issue with the patch it's used tmt -a provision -h local which IIUC it's the local host already executing tmt, in this case the code raises again permissions issues when doing the chmod

Is your change here causing a regression? Or is your change here just making no difference WRT #2877?

Summary from the chat discussion: /tests/provision/facts/guest should be adjusted to use the container image with password-less sudo that is localhost/tmt/tests/container/fedora/39/unprivileged and we will explicitly document that one of the following is needed on the guest:

• root user (with all permissions)
• regular user (with password-less sudo configured)

It seems now there's an issue when setting the ACLs, the user doesn't have permissions

cmd:
            mkdir -p /var/tmp/tmt;
            setfacl -d -m o:rX /var/tmp/tmt
            err: setfacl: /var/tmp/tmt: Operation not permitted

Also I see some extra error about an rsync command along with the following message
fail: Failed to push workdir to the guest. This usually means that login as 'fedora' to the guest does not work.

I see now the failed tests are
/tests/core/environment-file

:: [ 10:30:11 ] :: [   FAIL   ] :: Command 'tmt run --environment STR=bad_str -rvvvddd plan --name /plan/good 2>&1             | tee output' (Expected 1, got 2)
:: [ 10:30:11 ] :: [   FAIL   ] :: File 'output' should contain 'AssertionError: assert 'bad_str' == 'O'' 

/tests/prepare/ansible

:: [ 10:54:20 ] :: [   FAIL   ] :: Command 'tmt run -i /tmp/tmp.7zaDNljweN --scratch -av provision -h container -i localhost/tmt/tests/container/alpine:latest plan -n /remote' (Expected 0, got 2)
:: [ 10:54:20 ] :: [   FAIL   ] :: File '/tmp/tmp.7zaDNljweN/log.txt' should contain 'ansible-playbook -vvv' 

Sorry I don't see how is this related with the patch... 😕 @happz @psss could you shed some light here?

Hmmm, these seem to be caused by GitHub randomly refusing to serve the raw content:

fail: Failed to fetch remote playbook 'https://raw.githubusercontent.com/teemtee/tmt/main/tests/prepare/ansible/data/playbook.yml'.
403 Client Error: Forbidden for url: https://raw.githubusercontent.com/teemtee/tmt/22a46a4a6760517e3eadbbff0c9bebdb95442760/tests/core/env/data/vars.yaml

Sounds like they enabled some rate limiting, or we hit the limit:

• https://stackoverflow.com/questions/66522261/does-github-rate-limit-access-to-public-raw-files

Any suggestions?

I see this test case is also failing:

Command '
mkdir -p /var/tmp/tmt;
setfacl -d -m o:rX /var/tmp/tmt
' returned 1.

# stderr (1 lines)
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
setfacl: /var/tmp/tmt: Operation not permitted
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think the same approach for the pidfile can be used?, something like:

sudo = 'sudo' if not self.facts.is_superuser else ''
...
    {sudo} setfacl -d -m o:rX {workdir_root}
    """))

what do you think? @psss @happz

I think the same approach for the pidfile can be used?, something like:

sudo = 'sudo' if not self.facts.is_superuser else ''
...
    {sudo} setfacl -d -m o:rX {workdir_root}
    """))

what do you think? @psss @happz

Yes, I think sudo should be used here as well. This part of code is under the following condition:

if not self.facts.is_superuser and self.become

Meaning that we should probably use it here always. @happz, any thoughts?

@carlosrodfern, as this setfacl code was submitted by you, do you have any additional recommendations here?

Anyway, this is too late for 1.39. Let's merge this as one of the first changes in 1.40 in order to give it some testing.

For what I can understand, when the sudo mkdir -p is run with the pid directory, which goes pass /var/tmp/tmt/, then the whole structure is created owned by root. So, when it gets to the setfacl part, it fails. I would be also surprised that the chmod ugo+rwx is enough in a umask 0027 scenario. Wouldn't it better to create /var/tmp/tmt first with the corresponding acl to avoid issues with umask 0027, and then do the nested dirs?

I may be missing something too...